In the Third Generation Partnership Projects (3GPP) and 3GPP Long-Term Evolution (LTE) system, there exists a PDCP layer in the air interface protocol stack of User Equipment (UE) and NodeB (eNB). FIG. 1 is a schematic diagram of protocol stack of LTE user plane according to the related art. As shown in FIG. 1, the PDCP protocol layer is over the Radio Link Control (RLC) layer, and provides data convergence services for high-layer user plane data (such as user IP packets) or control plane data (such as Radio Resource Control (RRC) message).
FIG. 2 is a functional and structural schematic diagram of the PDCP entity according to the related art, which, as shown in FIG. 2, includes a Transmitting PDCP entity and a Receiving PDCP entity, wherein the main functions of the PDCP layer include: providing Header Compression and Header Decompression functions for the user-plane (u-plane) data, namely, the PDCP performing data header compression using Robust Header Compression (RoHC) protocol of Internet Engineering Task Force (IETF); providing Ciphering and Deciphering functions for the u-plane data and control plane (c-plane) data; providing Integrity Protection and Integrity Verification functions of data for the c-plane data; and providing Sequence numbering and Re-ordering functions for high-layer data, and enabling lossless handover, in the event of handover.
The PDCP transmitting entity assigns a Sequence Number (SN) to a high-layer Protocol Data Unit (PDU), namely, PDCP Service Data Unit (SDU). FIG. 3 is a schematic diagram of the format of PDCP PDU data packet according to the related art. As shown in FIG. 3, the assignment of SN is performed according to Data Radio Bearer (DRB). However, for the control data within the protocol layer, such as RoHC feedback, Status Report, etc., no SN is assigned.
In the event of handover, for the services which are sensitive to packet loss (such as file transfer, which, among other services, is generally transmitted by RLC Acknowledged Mode (AM)); lossless handover can be ensured by exchanging PDCP status report between the PDCP layer entities of the UE and the eNB. FIG. 4 is a schematic diagram of the procedure of lossless handover according to the related art. As shown in FIG. 4, the procedure of lossless handover is described taking uplink data transmission as an example.
Step 401: the UE transmits PDCP PDU 1, 2, 3, 4, 5 to the source eNB. But for some reason, the PDU 3, 5 are not successfully received by the source eNB.
Step 402: the source eNB transmits RLC acknowledgement (ACK) of PDU 1, 2 to the UE RLC entity.
Step 403: the UE is handed over from the source eNB to the target eNB.
Step 404: the source eNB notifies the PDCP SN status to the target eNB by SN STATUS TRANSFER message through the X2 interface.
Step 405: the target eNB transmits a PDCP status report to the UE, wherein it is indicated in the PDCP status report that the First Missing Sequence (FMS) is 3.
Step 406: the UE retransmits the PDCP PDU 3, 4, 5 to the target eNB.
FIG. 5 is a schematic diagram of the format of a PDCP status report control PDU packet according to the related art. As shown in FIG. 5, the transmission mechanism in the existing PDCP status report has two problems:
1. the PDCP status report is only used in the event of handover; and for the UE which is not in the handover procedure, the PDCP SN status cannot be exchanged between the UE and the eNB. However, in fact, in the non-handover, failures may occur in the PDCP layer of the UE or the eNB, for example, a RoHC header decompression failure; or repeated transmission of data due to the loss of the RLC acknowledgement in air interface transmission. If the PDCP of the UE or the eNB can also exchange the PDCP status information in non-handover, it will be helpful for the PDCP entity in avoiding packet loss or repeated transmission of packets which have been successfully received.
2. the PDCP status report can only be decided by the PDCP entity of the UE or the eNB to transmit or not after a handover (the selection is non-mandatory), and if the PDCP status report is not transmitted, then the opposite PDCP layer could not get the PDCP status information.
In addition, the wireless Relay technology is introduced in the 3GPP LTE-Advanced (LTE-A) system, in order to extend the coverage area of the cell, reduce blind angles in communication, balance the load and transfer the services of hot spots. FIG. 6 is a schematic diagram of the network structure into which a wireless relay node is introduced, according to the related art. As shown in FIG. 6, new Relay-Nodes (RNs) are added between the Donor-eNB and the UE, these new RNs are wirelessly connected with the Donor-eNB, and have no wired connection with the transmission network, wherein the air interface between the Donor-eNB and the RN is referred to as Un interface, and the wireless link between the Donor-eNB and the RN is referred to as Backhaul Link; and the air interface between the RN and the UE is referred to as Uu interface, and the link between the RN and the UE is referred to as Access Link. The downlink data reaches the Donor-eNB first, then is transmitted to the RN, and then is transmitted to the UE by RN, and reversed situation is applicable to the uplink data.
The PDCP data transmission of the UE under the RN is achieved through two parts, the first part is among the PDCP entities at the Uu interface, and the second part is among the PDCP entities at the Un interface. When a handover occurs to the UE served by the RN, considering the above mentioned lossless handover procedure, at the moment, the PDCP status transmitted between the RN and the target eNB only contains the SN status information among the PDCP entities of the first part, and the PDCP status transmitted among the PDCP entities of the second part (RN-Donor eNB) is not available in the existing mechanism. Therefore, during the handover procedure, the packet lost due to transmission errors in the second part cannot be re-transmitted in the target eNB.
In addition to the problem of inaccurate PDCP SN status information in the handover in the Relay scene, there is a new problem in the handover in the Relay scenario, and the new problem lies at the repeated data forwarding between the Relay and the Donor eNB during the handover procedure. When the UE served by one Relay is switched to the Donor eNB or other neighboring eNB, the Relay needs to forward the data (for the data in the RLC unacknowledged mode (UM), the data herein indicates data that has not been transmitted downwards yet; and for the data in the RLC AM mode, the data herein indicates data that has not received the RLC ACK yet), which has not been transmitted successfully, to the Donor eNB through an X2 interface. Since the data is originally transmitted to the Relay by the Donor eNB through the Un interface, and now needs to be transmitted from the Relay back to the Donor eNB, in consideration of the fact that the UE handover under the Relay may be relatively frequent, this unnecessary data forwarding is the resources waste of the Un air interface. One solution is: after successfully transmitting the PDCP data packet in the Un interface, the Donor eNB does not immediately delete the PDCP data packet from the buffer area, but wait until the Relay has successfully transmitted the PDCP data packet to the UE, which requires flexible exchange of the PDCP SN status information between the Relay and the Donor eNB.
In regard to the problem of packet loss and data retransmission due to the PDCP entity transmission errors in the related art, no effective solution has been proposed so far.